In recent years, mobile wireless communications have become increasingly popular. Initial implementations of mobile wireless communications, for example in the form of cellular telephone networks, supported circuit switched voice communication services. Today wireless carriers also offer packet data communication services to their mobile customers.
Prepaid communications services, in which a customer or subscriber prepays for usage of a communications system, have become increasingly popular. Such services now encompass an array of mobile wireless communications. In an example of a prepaid wireless service, the customer may purchase blocks of time for making voice telephone calls via a cellular telephone network. Upon connecting to the wireless communications network, the customer account is authorized and authenticated, and the network allows a call to proceed. The network monitors the customer's usage time and decrements from the customer's account. If the account becomes depleted, the system can either prompt the customer to purchase more time, or the system can terminate the call. Prepaid wireless communications system enable the customer to budget an amount of airtime that will be used during a certain period of time, and to insure that the budget will not be exceeded unless the customer purchases more airtime. The wireless service provider likes this type of service, because the carrier receives payment in advance and need not run the risk that the customer will default on a bill, as sometimes happens with postpay type billing services.
Service providers have extended their prepaid offerings to encompass various wireless data services. For example, commonly assigned U.S. patent application Ser. No. 10/247,034 to Varsha Clare et al. discloses a “Method and System for Processing Prepaid Wireless Data Communications.” As disclosed there, a receiving node, such as a packet data serving node (PDSN), handles packet data calls and interacts with an administration system, including an authentication, authorization and accounting (AAA) server and a prepaid server platform. Upon receiving a packet data call, the PDSN accesses the AAA server to obtain call access authorization. For a prepaid customer, with the authorization, the PDSN also receives a prepaid volume record indicating an amount of prepaid units available for use by the customer and processing instructions, from the server platform for the prepaid service. The PDSN then enables the wireless data call to proceed on the network, while monitoring the call and decrementing the available prepaid units from the prepaid volume record associated with the customer. If the available prepaid units reach a predetermined level, as indicated in the processing instructions, the PDSN notifies the prepaid service server that the predetermined level has been reached. The server system can respond either with an updated available balance, which enables the PDSN to allow the call to continue, or with instructions to the PDSN to terminate the call.
As another example, US published patent application no. 2004/0106393 relates to “Methods, systems and program products for supporting prepaid service within a communication network,” specifically for a prepaid packet data communication service. A prepaid client, for example in a foreign agent (FA) PDSN or in a home agent (HA), sends a resource request for prepaid resources through the network to a prepaid server. In response, the prepaid server transmits a resource response that specifies a quota of prepaid resources. The quota is no greater than the prepaid account balance of the subscriber. The resource response also includes a resource usage threshold at which the prepaid client will provide notification and will update the account to reflect a portion of the prepaid account balance that has been consumed.
Hence, a modern prepaid data (PPD) service allows the subscriber to pay for packet data service prior to usage. In an actual deployment, when a subscriber establishes a prepaid account with the wireless service provider, for packet data service, appropriate provisioning is made at the carrier's Authentication, Authorization and Accounting (AAA) and prepaid server platforms, to allow the subscriber to receive prepaid data service. The AAA server acts as a proxy for the prepaid user's Remote Authentication Dial-User Service (RADIUS) messages, except for accounting messages. The AAA server proxies the RADIUS messages to the provisioned prepaid service platform. The AAA server adds relevant information (e.g., MIP attributes) to the received RADIUS messages from prepaid service platform.
The Packet Data Serving Node (PDSN) and the Home Agent (HA) act as TIA-835-C prepaid clients. TIA-835-C is a standard for a 3GPP2 for a cdma2000 Wireless IP Network. In relevant part, that standard specifies a prepaid packet data service. The prepaid service platform acts as an TIA-835-C prepaid server (PPS). When the subscriber initiates a prepaid call, the AAA server proxies the RADIUS Access-Request to the prepaid service platform. The prepaid service platform checks the subscriber's balance, and prepaid and session termination capabilities of the serving PDSN and the customer's HA, and grants either the PDSN (for SIP sessions) or the HA (for MIP sessions) prepaid client (PPC) duties by providing a quota to the node serving as the PPC for the particular call.
The PPC carries out quota replenishment after threshold expiry using RADIUS online Access-Requests, which contain the amount of duration/volume used for that session. The PPC will release resources when the quota is not replenished and runs out, essentially ending the data session. When the subscriber ends a packet data session or the PPC is remotely instructed to tear down the session (by the prepaid platform), the PPC sends the information regarding the duration/volume used during the session, via the AAA server, to the prepaid platform.
The deployment using this standard-based technology tends to treat all packet data communications the same, for prepaid accounting purposes. However, packet data usage differs, typically with different applications that utilize the packet transport; and service providers may want to differentiate for billing purposes. Typical data communication applications include web browsing, application downloading and e-mail communication. However, as the speeds of packet-switched communications equipment and the speed of processors have increased, a variety of applications have emerged that utilize IP packet transport as an alternative bearer for voice communications. Such applications are often referred to as “Voice over IP” or “VoIP” services. Although originally developed for wireline network transport through the Internet and through wireline intranets, VoIP services are now migrating onto the packet transport networks deployed for the wireless domain. For example, it is now being proposed to use packet communications and VoIP to provide a push-to-talk (PTT) wireless broadcast communication service. It is desirable to differentiate VoIP communications, like PTT, from other packet data communications for prepaid billing purposes.
However, under the TIA-835-C standard for the prepaid packet data service, the only differentiated charging mechanism provided is for the exemption of traffic being sent or received from a specified set of IP addresses from volume-based charging. There is no differentiated charging mechanism that can be used with duration-based prepaid accounting in this standard.
United States Patent Application Publication no. 20040148384 to Ramakrishnan et al. discloses a middleware platform for analyzing and rating packet communications, based on a customer's prepaid account information from a Service Control Point (SCP) and profile information provided by a rating service implemented within the middleware platform. The middleware platform includes a classification engine, which apparently classifies each packet based on information from various levels of the IP protocol stack. The classification engine develops a decision tree for the customer's data communications based on a rating plan provided by the user's profile. An analyzer captures and delimits each packet of the customer's data communication by type, in accord with the decision tree. The platform then monitors each type of data flow within a user's session and provides usage statistics, e.g. for prepaid service control or post-pay type billing.
United States Patent Application Publication No. 20040028055 to Madour et al. teaches differentiated accounting in a packet data network. A Packet Data Service Node (PDSN) performs accounting functions based on the IP address of a customer's Mobile Station. However, the PDSN can also provide differentiated accounting based on information related to a Corresponding Node (CN), that is to say the terminal or server with which the customer communicates over a packet data session. Accounting can be differentiated based on the other party's IP address, and possibly the application ID or port number, and/or the Quality of Service (QoS) for that session. The PDSN counts the traffic associated with the other party's IP address, and reports that traffic, along with the that party's information to a AAA server, and accounting can then be applied based on the other party's information. For example, a lower rate may be charged for downloading of game software from the service provider's own service than is charged for data communications with another mobile terminal. The Publication suggests that the accounting may be prepaid or post-pay. The background of this document discusses an earlier solution in which the PDSN maintained a table of destination IP addresses, and applied special accounting to a customer's session upon recognition that it was directed to one of the IP addresses listed in the table.
These approaches to differentiated accounting do packet by packet or flow classification and then report the usage in number of packets consumed or KB (kilo-bytes) sent for that application or flow. These techniques enable service differentiation, however, such techniques do not provide any options for duration based billing. Many customers prefer duration based accounting because it is far easier to understand than accounting based on number of packets or bytes of data.
Duration based accounting raises other concerns. For example, some applications always need to maintain a data connection, but while idle, involve communication of relatively few packets. For example, for Push-to-talk (PTT), each station of an on-line member of a PTT group maintains (keeps alive) a data link to a PTT dispatch server. However, actual VoIP packets are transported through the network only when one member pushes the PTT button on his or her mobile station and transmits audio to the other group members. Once the PTT capable device sets up a session, it is either used exclusively for PTT purposes or used exclusively for non-PTT purposes. However, current prepaid processing schemes do not differentiate between these two uses, particularly in a manner that enables at least one application to be billed on a minutes of use basis. For an application like PTT, it would not be fair to charge by duration (minutes of use—MOU) for the entire time the user is logged-on for packet communication. However, when the same device is used for another application, for example web browsing, it may be appropriate to charge by duration of the packet data communication session.
Currently, it is not possible to distinguish, at the start of the data communication data session, whether the session has been setup by the mobile client device, for PTT use or for non-PTT use (e.g. BREW, mobile web). Hence a need exists for a technique to differentiate packet communications on a session level basis, for accounting purposes. For charging of a PTT subscriber, for example, the service provider needs to distinguish the PTT data session from the non-PTT data session and carry out the appropriate duration-based accounting for each type of session, e.g. to charge for duration of usage only on the non-PTT data sessions.